Digital certificates, also known as security certificates or simply “certificates”, utilize public keys and private keys to facilitate secure and validated transport of messages and information among people, computers, and servers. Digital certificates automate the process of distributing public keys and exchanging secure information. The digital certificate on a computer, server, web site, etc. has a public key that is freely available as part of the digital certificate and is given to those who wish to communicate with the device, who in turn use the key to encrypt messages sent to the certificate owner. The certificate owner also has its own private key that it uses to decrypt incoming messages.
Consider this example of communication using digital certificates. Whenever device A wishes to exchange information with device B, A accesses B's digital certificate, which contains B's public key. Then, A uses B's public key to validate B's identity and to encrypt the information to be sent. Only B's private key can decrypt this information once it is encrypted with B's public key.
In general, when a first device checks the identity of a second device against the identity conveyed by its certificate, the first device can be assured that the identity conveyed by the certificate of the second device is true and valid. However, if the certificate is invalid, because it has been stolen or otherwise counterfeited, then the identity of the second device can be falsified.
Once certificates are known to be compromised, they are revoked and added to the certificate authority's (CA) certificate revocation list (CRL). Given the potential for certificates to be compromised, it is important that those who receive messages, or otherwise need to verify identities, have a means for checking the validity of certificates. For example, if a rogue process counterfeits a server's certificate, a client might be duped into accepting this rouge server as a true server, and pass confidential credential information to the rouge server. Similarly, if a server is shown a counterfeit certificate from a client that it cannot determine to be invalid, it may give inappropriate access to this client.
In client-server systems, such as authentication, authorization, and accounting (AAA) client-server systems, digital certificates are used to verify the identity and validity of the clients and servers. This process typically involves four steps: validating the certificate using the trusted CA's public key, validating that the sender of the certificate is the owner of the private key, comparing the certificate content and the identity of the certificate sender, and checking the validity of the certificate.
Consider for example, a client verifying the identity of a server. In order to validate the server's certificate using the CA, the server first sends the client its certificate signed by the CA. Then, the client (e.g., a web browser) uses the public key of the CA to decrypt the certificate and thereby verify that the certificate has been encrypted using the CA's private key, which is held exclusively by the CA. If the decryption is successful, the client has verified that the CA has signed the certificate.
In order to validate that a server is the true owner of the private key, the server first encrypts a message using its private key and sends it to the client. Then, the client decrypts that data with the server's public key carried by the server's certificate. If the decryption is successful, the client has verified that the server truly holds the correspondent private key.
In order to compare the certificate content and the identity of the certificate sender, the client verifies that the certificate subject name contains the identity (e.g. domain name) of the server.
There are a number of possible ways to check the validity of the certificates. One set of solutions use the CA's CRLs to validate certificates. Such approaches are deficient in a number of ways. First, an interval for obtaining the CRL must be established. Consider a message passed at time T. If the interval for obtaining the CRL is based on passage of time, then, the longer the interval, the higher the probability that a certificate will be revoked between time T and the time when the CRL was last received. Conversely, if the interval is shorter, then the probability of missing a certificate revocation decreases, but not to zero, and the load on the network and on the CA increase unreasonably.
Another approach is to obtain either a CRL from the CA each time a certificate needs to be checked or to use the Online Certificate Status Protocol (OCSP) in order to obtain the information about that particular certificate. Both of these solutions require real-time interaction with the CA for each message validation at every client and server and would thereby unreasonably burden the CA and the network.
None of the above approaches adequately solve the problem of verifying the revocation status of a certificate.
Another problem with approaches to verify digital certificates deals with the multitude of formats that must be supported in a single system. In many approaches, it is required, when verifying a certificate, to know how to parse certificates in the incoming formats and to know which fields to compare. The fields can be as simple as name, location, and validity dates, but can also be specific uses of optional fields and, therefore, implementation dependent. The need to prepare for all of the permutations and possibilities related to certificate formats and uses increases the burden on and the expertise needed by the system administrators and implementers and increases the complexity of the code needed to implement the system.
There are many examples of authentication schemes such as those described above, including the 802.1x authentication scheme. The Protected Extensible Authentication Protocol (PEAP) and the Extensible Authentication Protocol/Transport Level Security protocol (EAP-TLS) also involve verification and validation of the client's and the AAA server's certificates. In the EAP-TLS and PEAP cases clients often cannot choose the AAA server with which to be authenticated. Therefore, the client should verify that it can trust the AAA server by examining server's certificate.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.